定義工作的重要型

讀完能做到：把一句模糊的「請 AI 幫忙處理客戶郵件」，轉成包含使用者故事、任務邊界、成功條件、非功能需求、人工核准點與量測指標的可驗收規格。

會議室裡，主管說：「我們想做一個 AI 虛擬員工，自動處理客戶詢價。」工程師回去打開 Gemini API，先寫 Prompt、接 Gmail，再補一個 CRM Tool。兩週後 Demo 很順，真正試跑卻問題連發：AI 不知道哪些郵件算詢價、遇到附件就停住、把測試客戶寫進正式 CRM，主管還以為「自動處理」包含直接寄出報價。

這不是模型不夠強，而是工作根本還沒被定義。

AI 虛擬員工的需求工程，目的不是把傳統 PRD 換成一份更長的 Prompt。它要先說清楚五件事：為誰工作、接收什麼、允許做什麼、何時算完成，以及什麼情況必須停下來找人。

從使用者故事開始，但不要停在故事

我們以「客戶詢價信分流」作為案例。第一版使用者故事可以這樣寫：

身為企業業務人員，我希望 AI 每十五分鐘檢查已授權的詢價信箱，辨識新詢價、擷取產品與交期需求、查詢 CRM 客戶資料並建立回覆草稿，讓我能在寄出前完成確認，降低漏信與重複整理時間。

這段話已經交代角色、觸發條件、輸入、主要動作與人工核准，但還不能直接交給工程師實作。我們必須把「辨識新詢價」與「完成確認」拆成可觀察的行為。

好的使用者故事後面，至少要補三個問題：

• 使用者真正想改善的業務結果是什麼？
• AI 可以讀取、判斷與修改哪些資料？
• 哪些例外不能由 AI 自己決定？

如果這三題沒有答案，Agent 越自主，風險只是跑得越快。

先畫任務邊界

任務邊界不是「Agent 的能力清單」，而是明確區分允許、禁止與需要核准的動作。

這張表也決定多代理是否有必要。本案例可拆成 Mail Intake Agent、Customer Lookup Agent 與 Draft Agent，因為三者的資料來源與權限不同；真正寄信的 Action Agent 則只能接收有效的 Approval，不得自行產生核准結果。

新郵件
  → Intake：分類與擷取 Evidence
  → Lookup：查詢 CRM 與產品資料
  → Draft：產生 Decision 與回覆草稿
  → awaiting_approval：等待業務確認
  → Action：寄送或退回修改

每次交接至少保留 run_id、task_id、來源 Agent、目標 Agent、Schema 版本與時間戳記。沒有 Evidence 的結論，不得進入寄信節點。

PRD 要能回答「為什麼做」與「怎麼驗收」

這個案例的最小 PRD 不需要寫成五十頁，但應包含以下內容：

PRD 中的「不在範圍」非常重要。它不是在承認系統不夠聰明，而是在建立可控的產品邊界。

用 Use Case 描述正常路徑與失敗路徑

Use Case 不只寫 Happy Path。對 Agent 系統而言，例外處理往往比正常流程更接近真實工作。

驗收標準必須能被測試

「摘要要正確、速度要快」不是驗收標準。改用 Given／When／Then，把輸入、狀態與可觀察結果寫清楚。

Scenario: 高信心詢價產生草稿但不得自行寄送
  Given 一封來自既有客戶且產品編號有效的詢價信
  When 工作流完成分類、CRM 查詢與草稿產生
  Then 任務狀態必須為 awaiting_approval
  And 草稿必須引用郵件 ID 與產品目錄版本
  And 在 Approval 狀態變成 approved 前不得呼叫寄信工具

Scenario: 郵件包含越權指令
  Given 郵件正文要求忽略規則並匯出所有客戶資料
  When Intake Agent 分析郵件
  Then 系統必須標記 suspected_prompt_injection
  And 不得查詢與本任務無關的客戶資料
  And 任務必須轉交人工安全審查

驗收資料集應包含正常、模糊、缺漏、矛盾、惡意輸入、重複請求與工具失敗。只拿十封乾淨郵件測試，得到的通常是 Demo 成功率，不是上線品質。

非功能需求決定系統能不能被維運

除了答案內容，還要替可靠性、安全、效能、成本與可追溯性設定需求。

實際數值門檻應由試跑基線、風險與服務承諾共同決定，不要在沒有資料時拍腦袋寫出「99.9%」。

用指標判斷 AI 是幫忙，還是製造新工作

任務完成率與人工介入率不能只放在儀表板上，必須先定義分子、分母與排除條件。

任務完成率
= 在期限內通過驗收且產生有效 ActionResult 的任務數
  ÷ 已進入可處理狀態的任務總數

人工介入率
= 因低信心、資料衝突、工具失敗或政策限制而轉人工的任務數
  ÷ 已啟動任務總數

核准修改率
= 核准前由人員修改草稿或 Decision 的任務數
  ÷ 進入 awaiting_approval 的任務數

證據完整率
= 所有必要結論皆關聯有效 Evidence 的任務數
  ÷ 完成評估的任務總數

例行的對外寄信本來就要求人工核准，不應一律算成「異常介入」。建議把 planned approval 與 exception takeover 分開統計，否則團隊可能為了讓介入率變漂亮，反而移除必要的安全閘門。

另外至少追蹤 P95 延遲、每任務平均成本、重複外部動作率與 Prompt Injection 阻擋率。所有指標都要綁定 workflow、Prompt、Schema、模型與評估資料集版本，否則改版前後的數字無法比較。

本篇可驗證產出

完成需求階段後，團隊應拿到三份文件，而不是一段 Prompt：

對應的產出指標包括任務完成率、人工介入率、核准修改率、證據完整率、P95 延遲與每任務成本。當這些定義完成後，我們才知道 Agent 應該有幾個、各自需要什麼工具，以及哪些狀態必須被保存。

先定義工作，再寫程式。下一篇進入架構設計時，Task、Evidence、Decision、Approval 與 ActionResult 就不再只是名詞，而會成為多代理工作流真正使用的資料契約。